【AWS Summit Tokyo 2019 セッションレポート】サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造 #AWSSummit

AWS Summit Tokyo 2019

#レポート

#セッションレポート

#イベントレポート

#Amazon Aurora

#Amazon RDS

かずえ

2019.06.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Tokyo 2019 Day2 （本日6/13）のセッション、「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」をレポートします。面白かったです！

ライブストリーミングでのセッション参加のレポートです。

セッション概要

このセッションでは、クラウドの技術革新を活用するためにゼロから設計された、クラウドネイティブデータベースサービスであるAmazon Auroraについて詳しく説明します。 Auroraはその記憶域として分散型マルチテナントログ構造化ストレージサービスを使用するなど、モノリシックデータベーススタックをサービス指向アーキテクチャに移行しています。 Auroraは、低レイテンシーレプリカなど、数々の革新的な機能を備えています。このセッションでは、主なイノベーション、パフォーマンス結果とその達成方法の確認、そして実際のアプリケーションについてお話しします。

スピーカー

Amazon Web Services, Inc. Aurora, MySQL, and MariaDB Senior Product Manager Yoav Eilat

セッションレポート

Auroraの紹介

コマーシャルデータベースの性能と可用性
オープンソースデータベースのシンプルさとコスト効果
MySQL,PostgreSQLとも互換性がある
従量課金

Aurora performance & scalability

Aurora Scale-out、distributed architecture

Shared storage volumeが存在、重要な役割を司っている
ページへの書き込みなど
3つのAZに2つずつ6つのデータコピーを作成
10GBずつデータが書き込まれる 64TBまで自動スケール

Six-way replicated storage

6の非同期並列書き込みのうち4つのストレージにデータが書き込まれたらコミットされたとみなす
読み込みは3つ
ノードの修復は Peer to peer "gossip protocol”を利用
例 4つのトランザクションからPage1書き込む例で説明
クラッシュがあった場合、4つに到達する前にクラッシュした場合はトランザクションされてないと通知される

I/O flow in Aurora storage node

ログレコードを受信してインメモリキューに追加
ホットログとACKでレコードを保持
レコードを整理し、ログのギャップを特定
ギャップを埋めるためにゴシッププロトコルを利用
ログレコードを新しいページバージョンに結合
定期的にログと新しいページのバージョンをS3に保存
定期的に古いバージョンをガベージコレクション
ブロックのCRCコードを定期的に検証

注目点
2終了時点で結果がインスタンスに返される
4で前述のゴシッププロトコルが使われている
6 s3にログと新しいページのバージョンを定期的に保存

Write and read throughput

通常のMySQLの5倍ほど早い

Bulk data load performance

MySQLの2.5倍ほど早い PostgreSQLより2倍ほど早い

Continuous HW upgrades

2015年のリリース以降、常にパフォーマンスが改善されている
間も無くR5インスタンスリリース

Aurora Read Replicas

一つのMaster
最大15個のRead Replica
レプリカの遅延がかなり低い 10ms未満
フェールオーバーの順序を設定可能（どのリードレプリカを最初にMasterに昇格させるのか）

MySQL vs Aurora I/O profile

Auroraはストレージが共有されているからレプリカアップデートが早い

通常のMySQLは(レプリカアップデートまでに)5つのステップが必要

プライマリのストレージに書き込み
プライマリのバックアップストレージに書き込み
リードレプリカにデータを送る
レプリカのストレージに書き込み
レプリカのバックアップストレージに書き込み

- Aurora - プライマリでの書き込みで最低4つのストレージノードへの書き込み完了まで待つ必要がある - レプリカは何も書き込む必要がない　ストレージが共有されているから - トランザクション35倍増化 - IOの数は約1/8

Aurora read replicas are dedicated to reads

Auroraが良いところはレプリカは100％Readに特化すれば良いところ (Writeはすでにプライマリが行なっていてそのストレージを共有しているから)
だから早い！

Aurora read Scaling options

クラスタ毎に昇格可能な15台のレプリカ
自動増加・削除を行うAuto-Scalingレプリカ
リージョンをまたいだリードレプリカ(Aurora Global Database)
binlogを利用したレプリケーション
オンプレにレプリケーションもできる

Aurora Global Database(リージョンをまたいだリードレプリカ)

インスタンスではなくストレージがレプリケーションを行なう

High throughput :Up to 200K writes/sec
Low replica lag: < 1 sec cross-country lag
Fast recovery: < 1 min region unavailability

Global replication performance

遅延が非常に短い
秒間クエリ数は多い

Aurora Parallel Query

Aurora ストレージには数千のCPUが存在
一部をインスタンスではなくストレージノードで処理することで
データに近いところで処理可能
ネットワークトラフィックと待ち時間を削減

Parallel Query performance results

Netflixの事例
120倍早くなったクエリがある
22クエリのうち8クエリが10倍以上早くなった

Aurora lock management

MySQL 大きなロックが他を待たせてしまう　デッドロック発生
Aurora 複数のスキャナが存在　ロックがそれぞれに管理されている

可用性

Instant crash recovery

従来のDB
チェックポイント間は通常5分
最新のチェックポイントのログからリカバリ
Aurora
チェックポイントという概念がない
ストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで最適用
起動時に最適用無し

Cluster Cache Management - Aurora PostgreSQL

Avoiding a cold cache after failover

ピチピチの新機能!
https://aws.amazon.com/jp/about-aws/whats-new/2019/06/amazon-aurora-with-postgresql-compatibility-supports-cluster-cache-management/
Cluster Cache Management無しでデータベースをフェールオーバーすると
32秒でデータベース起動
パフォーマンスの90％を回復するのに340秒かかる(キャッシュウォームアップに時間がかかるから)
Cluster Cache Management(CCM)があると
DBはウォームアップされたキャッシュにフェールオーバー。フェイルオーバーから32秒後にパフォーマンス回復